The Internet may be described in a simplified manner as a collection of computer systems that are interconnected by public/private networks (e.g., using transmission lines and gateway servers) to enable the transfer of information among them. Theses networks include the public switched telephone networks (PSTN) that transport voice over dedicated connections and data networks that employ switches and/or routers to transport data (e.g., text, voice, video, etc.).
Telephone and data network infrastructures are usually deployed together with limited sharing of resources, especially with regards to the network gateway, or access, servers (e.g., switches and routers) that direct the data payloads throughout the networks. Furthermore, the network access servers (NAS) that are used to provide a data path, or interface, between multiple networks that each may operate according to a different networking standard protocol. Examples of the networking protocols supported by these gateway servers include, for example, Internet Protocol (IP), frame relay, T1 channelized, E1 channelized, and Asynchronous Transfer Mode (ATM). The cost of this redundancy coupled with advances in data network technology has led, where possible, to integrated network traffic comprising voice, video, data, facsimile, and modem information over a unified data network that is interfaced by multiservice NAS.
FIG. 1 illustrates a conventional NAS in which an array of digital signal processors (DSP) is typically required to perform digital signal processing operations on a number of channels of data. For modem and facsimile traffic, the DSPs are mostly used to modulate and demodulate the traffic to and from the dial-up telephone access links. For a voice call over the same link, the same DSP can instead be used to compress and decompress the voice traffic towards and from the core of the data network, to suppress undesirable echoes which usually arise at various points in the network, to suppress unnecessary silent packets to preserve network bandwidth, and to detect end-to-end voice activity to save data network bandwidth. A host bus and host processor typically communicates payload data between the DSP array and the data network side of the DSP array. While the host bus may include a number of channels of information, the typical system permanently assigns each channel to a particular DSP of the array.
As mentioned, one or more of the DSPs in the array may be used to compress and convert Time-Division-Multiplexing (TDM) streams from a PSTN into IP packets. The NAS receives the TDM signals, for example, through a T1 or E1 line, and converts them into IP packets. The packets are then transmitted through a network interface (e.g., Fast Ethernet) over an IP network. An Internetwork Operating System (IOS) runs on a central processing unit (CPU) of the NAS and can be used to track and control the operation of the DSP array. DSPs can also be used, for example, in Voice-over-Asynchronous Transfer Mode (VoATM), Voice-over Frame Relay (VoFrameRelay), and other similar applications.
Unfortunately, DSPs have limited computational power, measured in terms of a number of Million Instructions Per Second (MIPS). A DSP, therefore, can only process a limited number of channels. The number of channels that the DSP can process depends primarily on the complexity of a compression coding and decoding (codec) type used for the channels. The different channels can either have the same codec type or different codec types. For example, a typical model C549 DSP, manufactured by Texas Instruments (TI), has 100 total available MIPS and can, for example, process eight channels of G.711 calls, or two channels of G.711 calls plus three channels of G.729a calls. FIG. 2 illustrates a table identifying various codec types and their associated processing bandwidth requirements.
A typical VoIP call on a DSP is set up in two steps. These steps are primarily dominated by the VoIP protocol and are therefore not implementation specific. In a first step, the voice channel is opened on a DSP with the minimum allowable MIPS consumption (e.g., 12 MIPS) preallocated. At this time, the DSP does not have any information on what codec type will be used once the channel is established. The codec type is determined through negotiation between the voice entities. The codec information is typically carried by an H.323 capabilities exchange or in a Media Gateway Control Protocol (MGCP) ModifyConnection (MDCX) package. In a second step, the codec type is set on the DSP and more MIPS are acquired, if needed. Additional MIPS may be required, for example, if a higher complexity codec type is selected. For example, if a G.729a codec type is to be used, an additional thirteen MIPS (25 required MIPS−12 preallocated MIPS=13) are required by the voice channel.
The first step of the call setup can occur at the same time for multiple VoIP calls, before any of those calls reach the second step. Accordingly, unless an effective method of managing DSP resources (e.g., available MIPS) is provided, the DSPs may have unbalanced load, resulting in inefficient DSP utilization.
Existing methods for managing DSP resource include a “channel-oriented” approach and a “complexity-oriented” approach. In the conventional “complexity-oriented” resource management approach, DSP resources are managed based on an allocation of MIPS. Using this approach, the DSP with the most available MIPS is chosen to open a call channel. The call is prematurely disconnected, however, if it later requires more MIPS than are available. The primary drawback to this approach is that the “maximum MIPS” rule used to select the DSP during the first call setup step may not allocate voice channels to the most appropriate DSP. This can result in one or more, or all, of the channels later being prematurely disconnected. A substantial amount of the available bandwidth on a DSP may therefore not be utilized.
In the channel-oriented approach to DSP resource management, a fixed number of channels are established per DSP. For example, a DSP can be configured to process up to four voice channels, no matter which codec type is used. The drawback of this approach, however, is that a DSP using this scheme generally has fewer channels established than it is capable of handling. In the example above, for instance, the DSP is limited to processing a maximum of four channels of G.711 calls even though it can actually handle eight channels of this codec type. One method of managing DSPs in a channel-oriented approach is discussed in U.S. Pat. No. 6,584,108, illustrated in FIG. 3. In U.S. Pat. No. 6,584,108, a DSP resource manager maintains three types of pools: a free DSP device ready pool which contains whole (unfragmented) DSPs; an active DSP channel pool which contains DSP voice channels being used, and; a multiple free DSP channel ready pool, each containing several DSP channels with pre-loaded codecs. Practically, each pool is composed of one G.711 channel and multiple compression codec channels (e.g., G.729a, G729, G711, etc.). Per the discussed method, a DSP must be fragmented into channels. Each channel is pre-loaded with a certain codec type (composing a pool). When a call comes in, DSP resources are selected from one of the pools, with preference calculated by weight, fragmentation factor and number of channels in a pool. If the existing DSP channel ready pool cannot satisfy the codec requested from a new call, and if there is no unfragmented DSP (i.e., the free DSP device ready pool is empty), the certain channels in the DSP channel ready pool are reloaded. The method tries to maintain channels with the same codec on the same DSP and tries to maintain as many unfragmented DSPs as possible. Such a method may not maximize the use efficiency of the DSPs.